home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Arsenal Files 2
/
The Arsenal Files 2 (Arsenal Computer).ISO
/
lan
/
ngm192.exe
/
README.UPG
< prev
next >
Wrap
Text File
|
1994-05-25
|
35KB
|
701 lines
┌───────────────────────────────────────────────────┐
│ │
│ NetWare Global MHS │
│ Upgrade 2.0C for NW4.01 │
│ May 23, 1993 │
│ │
└───────────────────────────────────────────────────┘
UPGRADING FROM NGM v2.0b to v2.0c
_________________________________
This file describes the steps required to upgrade NetWare Global
MHS from version 2.0b to version 2.0c.
This upgrade provides the following changes:
1. Illegal Memory Access:
o NGMINS and NGMDEINS were passing a memory block
without calling InitScratchMemory.
o NGMEXTRC was trying to initialize an invalid handle
which is no longer used.
o NGMUPGRADE was passing an absolute pointer to create
screen. This pointer is not valid in the upgraded NUT.NLM.
o NGMADMIN was allocating memory using malloc and was
trying to deallocate it using FREE() instead of free().
o NGMADMIN abended when deleting a gateway host. This problem
was resolved by checking the pointer to the gateway host name
before deleting it.
o NGMSMF abended when adding a new application.
Problem resolved by passing the correct pointer to application
record.
2. Unreleased Resources:
o When any module is loaded with -s option CreateScreen
allocates memory . This memory was not released when
the module was unloaded. Modified the modules DSYNC.NLM,
NGM.NLM, NGMEXTRC.NLM, NGMSMF.NLM to use DestroyScreen()
to release the memory.
3. Misbehaviours:
o CMP now checks, during updates, that a deletion record's master
host and the original record's master host are the same.
This fixes the missing link problem.
o Fixed PMR: Deleting a record did not generate opcode (Delete)
in an ASCII CMP message. Check is made against PL_DESTROY instead
of PL_DELETE.
*NOTE* This patch is designed to upgrade NetWare Global Messaging
v2.0b to v2.0c. If you have a version other than an official
red box or patched version of NGM2.0b, this upgrade will not work.
To determine your current NGM version, type 'load MODULES' at the
server console prompt and verify that the version number for
'NGMADMIN.NLM' is v2.0b. If you have any other version, contact
your local Novell representative to receive the appropriate upgrade
for your system.
WHAT DO YOU NEED TO DO FIRST?
_____________________________
Use this upgrade to modify an existing NetWare Global MHS installation.
Before you install this upgrade, verify that you have an official release
of NetWare Global MHS v2.0b installed on your system. For information on
installing NetWare Global MHS, refer to your "Installing NetWare Global
Messaging" manual, part number 100-001200-001.
WHICH FILES ARE UPGRADED?
-------------------------
This upgrade changes the following files.
1. NGM.NLM
2. NGMSMF.NLM
3. NGMAMP.NLM
4. NGMADMIN.NLM
5. NGMINS.NLM
6. NGMEXTRC.NLM
7. NGMDEINS.NLM
8. NGMUPGDE.NLM
9. NGMDSYNC.NLM
This upgrade does not change the serial number and maximum number
of licensed users for your NetWare Global MHS installation.
INSTRUCTIONS FOR INSTALLING GMHS ON NETWARE 4.01
________________________________________________
Please read this entire document before starting an installation of
GMHS on your NetWare 4.01 server.
This GMHS patch for NW 4.01 works in Bindery Emulation mode ONLY.
The following installation procedures MUST be followed to successfully
install and configure GMHS on a NW 4.01 server.
This patch version must be loaded ONLY on NW 4.01 (not 4.0) and you
must use the CLIB and Btrieve specified in this document.
Installing and configuring GMHS on a NW 4.01 server requires the following:
1. GMHS 2.0b software for NW 3.12 (Redbox or patch release)
2. GMHS 2.0c patch for NW 4.01 (Located on NetWire)
3. Proper versions of CLIB and BTRIEVE (Located on NetWire)
*NOTE* These files can be found on NetWire in the following locations:
BTRIEVE - NOVLIB Library 7 BTR61.EXE
BTRIEVE.NLM version 6.10C dated November 19, 1993.
(DO NOT use the CLIB version which is included in
this self-extracting archive)
CLIB - NOVLIB Library 4 LIBUP2.EXE
CLIB.NLM version 4.01D dated February 24, 1994.
Please make sure you have the installation media, the patch software,
and proper CLIB and Btrieve software, prior to proceeding with the
installation and configuration of GMHS on your NW 4.01 server.
USER ADMINISTRATION/ACCOUNT MANAGEMENT
______________________________________
This section describes the guidelines for setting up and managing MHS mailbox
accounts given the interaction between NDS and the Global MHS directory
through the bindery emulation. This section assumes the reader is familiar
with and understands bindery emulation and NDS.
For a successful installation, it is very important to take the time to
understand this section and understand the operation of your MHS application.
APPLICATION ISSUES
__________________
Most MHS applications have been developed with NetWare 3.x in mind. This means
the applications may make certain assumptions about bindery use, traditional
NetWare 3.x directory structures etc.. In determining how you will administer
and manage the system, you must take into account how the application is
affected by your system configuration. The following lists some of the known
issues that you should understand before starting. Please contact your MHS
application provider's documentation and/or tech support group to confirm these
items before you start.
1. Some applications make use of the SYS:\MAIL\<userid> directory structure
that was part of the NetWare 3.x system. NetWare 4.01 does not behave
thevsame in this regard in that it does not provide users access to
their SYS:\MAIL\<userid> directory by default. For example, Novell's
own FirstMail mail application uses the SYS:\MAIL\<userid> directory as
its default message store. If you upgrade your system from NetWare 3.x
to NetWare 4.01, your rights are likely preserved. If you have done a
fresh installation of NetWare 4.01, you must ensure that rights are
properly assigned.
2. MHS applications vary some in how they locate the \MHS directory tree.
Most applications use the MV environment variable (see Global MHS
documentation for details). If your application uses the MV variable
you must ensure this variable is properly set in your user's login
scripts. If other methods are used, you must understand how the
application is affected by the administration interactions described
below.
3. Some MHS applications use environment variables to determine what their
MHS mail address is while others use techniques that involve bindery
calls. If the applications use environment variables, then you only
need to make sure it is properly set as part of the login scripts. If
bindery calls are used, then you MUST carefully follow the procedure
recommended below and MUST NOT use the 'Advanced Configuration' method
since applications will be unable to determine their mail addresses in
that case.
OVERVIEW OF NDS/GLOBAL MHS INTERACTION
--------------------------------------
Global MHS uses bindery emulation to associate user accounts with physical
mailboxes. A mailbox account is created by either importing users from the
bindery or by adding users via NGMADMIN. Whenusing NGMADMIN to add a user,
the utility confirms the existance of the user's account in the bindery. If
there is no bindery user for the account being created, a new bindery entry
is added for the new mailbox account.
When using bindery emulation in NetWare 4.01, this Global MHS interaction with
the bindery indirectly introduces some dynamics with NDS. For instance, if
NGMADMIN is used to create an account forwhich no BINDERY entry exists, a new
bindery entry is created in the bindery context for that server. This causes
an NDS user object to be created at the same time in the container object
associated with the bindery context. Conversely, when NWADMIN is used to add
an NDS user object, a bindery entry is created for that user on every server
which uses that bindery context.
These two indirect interactions impose some constraints about managing Global
MHS mailbox accounts. Understanding the interaction model is very important to
ensure a successful deployment. To avoid complex manual administrative
intervention, there are 5 recommended general guidelines which will help you.
These are summarized in the following bullet points and will be explained in
the following sub-sections. By following these guidelines, the major features
of Global MHS will work successfully (e.g. bindery import, sender validation,
passive server, etc.). A more complex manual process can be achieved but is
not recommended since it adversely affects some of the Global MHS features.
o Each NetWare 4.01 server which acts as either an ACTIVE or PASSIVE
Global MHS server should use a bindery context which is unique for
the entire network.
o All NDS user accounts which are to have mailbox accounts on a common
Global MHS server should be in the bindery context which is unique to
that server.
o The Global MHS long-names in the Global MHS directory are independent
of the NDS names and a consistently applied naming scheme should be
employed for the Global MHS names.
o Global MHS mailbox deletion and NDS user object deletion are
independent events. If you delete a mailbox for a user, the NDS
account and bindery object remain intact. If you delete an NDS user
object, the mailbox remains intact (if one was created). You must
remember to delete accounts accordingly.
o Use consistent methods for adding, deleting, and moving users to avoid
missing steps that might cause conflicts in name or account locations.
This is important because there are multiple ways to add users to the
system and depending upon the method used, other procedures must follow.
If you follow these guidelines, existing bindery dependent applications and all
Global MHS features should work without any problem. However, you must confirm
application compatibility with your application provider.
UNIQUE BINDERY CONTEXTS
-----------------------
If more than one server shares a common bindery context, the binderies for
those servers will be identical. That is, user accounts in that context will
receive bindery accounts on each of the servers. If bindery import is used to
create Global MHS mailboxes and multiple Global MHS servers share the same
context, then each user in that context will end up with multiple mailboxes
(one on each Global MHS server sharing the same context). When Global MHS
synchronizes routes, conflicts can occur. This conflict will also exist for
a single Global MHS server which is the ACTIVE router for a PASSIVE Global MHS
system.
MAILBOX USERS IN THE SAME BINDERY CONTEXT
-----------------------------------------
When using bindery import in Global MHS, only NDS user objects in the bindery
context for that server will have bindery accounts that can be imported. NDS
user objects in different bindery contexts will be invisible to Global MHS and
therefore can not be imported. Therefore, if you want a user's mailbox to
reside on a particular Global MHS server, that user's NDS account must exist
in the bindery context for the target Global MHS server.
If you have an existing NDS structure where users from multiple contexts must
have mailbox accounts on the same Global MHS server, you must alter the NDS
structure. One way to do this is to move all of the desired users into the
same bindery context as the Global MHS server and then create NDS alias objects
in the contexts where the user account originally was located. This will allow
the users to continue to log in under their old NDS name (now an alias) while
meeting the requirements for Global MHS to operate.
*WARNING* If a user is in the wrong context and you create an alias in the
right context, the desired affect will NOT be achieved! The actual
non-aliased NDS object must be in the Global MHS server's context
in order for a bindery account to be visible to Global MHS.
If you choose to create Global MHS accounts using NGMADMIN, bindery accounts
will be created if the user does not exist in that context. This will create
an NDS account for that user in the bindery context of that Global MHS server.
You will likely want to then use NWADMIN to complete user account.
NDS/GLOBAL MHS DIRECTORY STRATEGIES
-----------------------------------
Global MHS maintains a directory of mailbox names. These logical names are
hierarchical location independent names in the same way that NDS names are
hierarchical and location independent. Because Global MHS is running in
bindery emulation mode, the Global MHS directory names are totally independent
of the NDS names. For example, the user Susan Jacobs might have an NDS name
of Susan.Jacobs.Marketing.San Fransisco.Acme and a Global MHS name of Susan
Jacobs @ Marketing.Acme. When logging into the network, the NDS name is
specified, but Global MHS knows Susan by the Global MHS name only.
To avoid confusion, a consistent naming strategy should be employed. There are
two recommended strategies. One strategy is to intentionally make the Global
MHS tree and the NDS tree naming conventions unique. The second strategy is to
make the Global MHS and NDS tree naming conventions identical. There are pros
and cons to each of these and each installation should decide which strategy is
best. Either strategy will be compatible with the upgrade for the forthcoming
NetWare 4.x NDS integrated MHS solution.
Unique naming conventions can be advantageous when people have selected NDS
conventions that are excessively long or suggest physical locations or
administrative partitions. For example, if you use naming conventions like
David Peterson.Segment 6.Building 3.Phoenix.Davis Corp, you will likely not
want the user's NDS name to be the mail name. Rather, you may find David
Peterson@Davis Corp to be more appealing for mail purposes. Taking advantage
of the independence between Global MHS and NDS naming allows you to construct
flat, concise mail directories while maintaining deeper more descriptive NDS
naming (for network admin purposes). The disadvantage of this scheme is that
users will be known by two logical names and there is no directly apparent
corelation between NDS name and the Global MHS name (visible via NDS or Global
MHS tools). This corelation can only be determined by finding the NDS and
Global MHS names which are associated with the same bindery account.
Identical naming conventions can be advantageous if you want users to only be
known by one logical name. For instance, if you want the NDS account Karen
Woodward.Engineering.Software Guru's to be known as
Karen Woodward @ Engineering.Software Guru's
in Global MHS, then identical naming strategies are appropriate. However, if
the NDS names you have are long complex names which are non-intuitive, then
identical naming may not work well for you.
*REMEMBER* The long name used in Global MHS is independent of the NDS name.
If your Global MHS directory tree matches your NDS tree (by
manually creating it this way), users will only be created in
the default bindery context even if the Global MHS name is a
different bindery context!! If you are using aliases to allow
people to log into different contexts but use a common server for
mail, you must manually create the NDS alias for the user object
created in the server's bindery context.
For example, you decide to create Jim Grubb @ Engineering.ABC by using NGMADMIN
but the default context for the server is Operations.ABC. NGMADMIN will create
a bindery account for Jim Grubb which results in an NDS user object
Jim Grubb.Operations.ABC. To keep the naming consistent, you must remember to
then use NWADMIN to manually create the alias Jim Grubb.Engineering.ABC and
associate it with the Jim Grubb.Operations.ABC user object.
Conversely, if you want to create users through NWADMIN. If you decide you
want Jim Grubb to have a mailbox on the server in the Operations.ABC context
and also be listed in the Engineering.ABC context, you must first create the
Jim Grubb.Operations.ABC user object using NWADMIN. You then create an alias
for Jim Grubb.Engineering.ABC which points to Jim Grubb.Operations.ABC.
Finally, if you use NGMADMIN to add Jim Grubb you must remember to manually
set the long name to be Jim Grubb @ Engineering.ABC.
ACCOUNT DELETION
----------------
Global MHS will not delete bindery accounts if the mailbox is deleted through
NGMADMIN. Generally, this is a desired behavior. Conversely, if you delete
an NDS user object which has a corresponding Global MHS account, the mailbox
is not deleted. This may not be the desired behavior since there is no longer
a user associated with the account. You must remember to delete the Global MHS
account separately from NDS user object deletion.
CONSISTENT ADMINISTRATION
-------------------------
The key to success is to employ a consistent administrative process for adding,
moving or deleting users. This will ensure that you don't miss steps or
introduce inconsistency in your naming strategies. For example, you might
decide to always add users by first adding them via NWADMIN and then adding
them through Global MHS bindery import (or NGMADMIN). Conversely, you might
decide to first create the mailbox account via NGMADMIN and then use NWADMIN
to complete account set-up. The following are two sample procedures you could
adopt.
User Add Procedure from NDS:
1. Add the NDS user object in the bindery context for the Global MHS
server where the mailbox should reside.
2. Create any needed alias for the NDS user object in different
context(s) if desired.
3. Use NGMADMIN to add the mailbox and set the MHS long name according
to convention used.
Delete User Procedure from NDS:
1. Note the MHS long name for the user to be deleted.
2. Delete the NDS user alias (if exists).
3. Delete the NDS user object.
4. Use NGMADMIN to delete the MHS account (noted from step 1).
User Add Procedure from Global MHS:
1. Use NGMADMIN to add the MHS user and set the long name according to
desired convention.
2. Use NWADMIN to edit the NDS user object in the context for the Global
MHS server.
3. Use NWADMIN to create any alias for the NDS user object (if
necessary).
User Delete Procedure from Global MHS:
1. Note the NDS account associated with the mailbox to be deleted.
2. Use NGMADMIN to delete the MHS account.
*NOTE* If you do not want to delete the user object, stop at this point.
3. Use NWADMIN to delete any alias associated with the NDS account noted
in step1.
4. Use NWADMIN to delete the NDS user object noted in step 1.
ADVANCED CONFIGURATION
----------------------
If you are willing to give up bindery import from Global MHS and do not want
to use sender validation, and if you are unwilling to have the restriction of
all unique bindery contexts for each Global MHS server with all MHS users in
the same context for that Global MHS server, you can do so. This is not
recommended because you must understand mailbox access rights controls in
addition to fully understanding the interaction issues of NDS (introducing
room for manual error). For those requiring this capability, this section
describes the procedure.
APPLICATION INCOMPATIBILITY WARNING:
If you use the following procedure, bindery accounts will not be available
will not be available for users in different contexts than the default
context of the Global MHS server. Applications that use bindery information
will not work for those users in other contexts. Refer to the earlier
section on Application Issues before proceding with this configuration.
OPERATIONAL WARNING:
If you use this process, you must not use bindery import from Global
MHS. Doing so will cause a host of problems. To reinstate bindery import
compatibility, you must completely restructure your NDS tree according to
the constraints listed under the recommended procedure. Secondly, because
Global MHS uses bindery file ownership for sender validation, validation
will not work. Third, any errors in setting up user rights in the MHS
directory structure may rendor your Global MHS system inoperable. Again,
Novell strongly recommends that you use the procedures listed earlier. This
information is only being provided as a matter of convenience for highly
skilled, and advanced MHS users who are willing to accept responsibility
for proper and fully manual administration.
User Add from NDS:
1. Add the NDS user object from NWADMIN in any desired context.
2. Use NGMADMIN to add a mailbox account and set the long name according
to your desired convention.
3. Assuming the NDS user object is not in the bindery context for the
Global MHS server, use NWADMIN to delete the user object that was
created when NGMADMIN added the bindery account for the new mailbox
account.
4. User NWADMIN to grant the NDS user object (created in step 1) proper
rights to the MHS mailbox directory created by NGMADMIN.
(\MHS\MAIL\USERS\<gmhs short name>).
5. Use NWADMIN to grand the NDS user object (created in step 2) proper
rights to the \MHS\MAIL\SND, \MHS\MAIL\PARCEL, and \MHS trees.
*NOTE* Refer to Global MHS documentation to learn how rights are
in the \MHS directory structure.
User Add from Global MHS:
1. Use NGMADMIN to add a mailbox account and set the long name according
to your desired convention.
2. Add the NDS user object from NWADMIN in any desired context.
3. Assuming the NDS user object is not in the bindery context for the
Global MHS server, use NWADMIN to delete the user object that was
created when NGMADMIN added the bindery account for the new mailbox
account.
4. User NWADMIN to grant the NDS user object (created in step 1) proper
rights to the MHS mailbox directory created by NGMADMIN
(\MHS\MAIL\USERS\<gmhs short name>).
5. Use NWADMIN to grand the NDS user object (created in step 2) proper
rights to the \MHS\MAIL\SND, \MHS\MAIL\PARCEL, and \MHS trees.
*NOTE* Refer to Global MHS documentation to learn how rights are assigned
in the \MHS directory structure.
UNRESOLVED ISSUES
------------------
This document will be updated pending verification of the following issues:
1. Compatibility with the SNADS protocol module.
2. Compatibility with the SMTP protocol module.
3. Compatibility with the Retix X.400 protocol module.
PROCEDURE FOR INSTALLING GMHS ON NETWARE 4.01
_____________________________________________
Step 1: Verify that the following NW 4.01 configuration parameters
are set as indicated. GMHS requires these parameters for
proper installation and operation.
a. Allow Invalid Pointers = ON
b. Read Fault Emulation = ON
c. Write Fault Emulation = ON
You can verify this by:
1. Loading SERVMAN.NLM on the system console
2. Selecting 'Console Set Commands'
3. Selecting 'Memory' option
If the above three parameters are not set to ON, please
change them. All three parameters should be turned ON.
Step 2: Establish the Bindery Emulation Context for all users on
that NW 4.01 server. This is done using NDS administration
utilities.
Step 3: Add the group EVERYONE to the NDS Container associated with
the above Bindery Emulation Context.
Step 4: If this context has a user called "Admin" then please rename
this user to avoid conflicts with GMHS's Admin user that is
normally associated with the "Supervisor" Bindery user.
Alternatively, make sure that the GMHS postmaster user is not
'ADMIN' (can be ADMIN1 for instance) in step 6.
Step 5: Load the following versions of CLIB.NLM and BTRIEVE.NLM:
CLIB.NLM version 4.01D dated February 24, 1994.
BTRIEVE.NLM version 6.10C dated November 19, 1993.
Step 6: Install GMHS from the media in the GMHS red-box following
GMHS installation guidelines. If you need to change the name
of the postmaster user from ADMIN to something else do so at
this stage.
Step 7: If you use the NGMStart.ncf file to run NGM you must edit
NGMStart.ncf to have it load the correct versions of CLIB
and Btrieve, specifying the directories where these new files
were copied to in step 5. Do NOT use CLIB and Btrieve installed
in the NGM\BIN directory by the GMHS install program.
Step 8: Execute the GMHS patch copied down from NetWire.
(See 'UPGRADING YOUR SERVER', below, for instructions on
the patch upgrade procedure)
Step 9: Load NGM following the instructions on running NGM.
*NOTE1* The following message may be displayed on the server console during
the installation of GMHS v2.0c on a NetWare 4.01 server:
"Read from a non-present page
Process: Pinstall.nlm 0
Module: NetWare Server Operating System
Code offset in module: FD006A3FH
Access address: 0000008EH"
This message should not be considered a problem and is to be expected
for an initial installation of GMHS v2.0c on NetWare 4.01.
*NOTE2* When this patched NGM.NLM software is loaded, you will see
the following warning message.
"This module uses 4 outdated API calls
You should upgrade to a newer module when it becomes available"
This message is for informational purposes only. This version
of NGM has been upgraded for NetWare 4. You should ignore this
warning message.
*NOTE3* There can be a NetWare problem when several multi-NLM products are
loaded from AUTOEXEC.NCF. The primary symptom is the server may
reboot itself while in the process of loading an NLM of a multi-NLM
product. This reboot may repeat several times before the server
manages to successfully come up with all products loaded. If you
experience this symptom and your AUTOEXEC.NCF is loading multi-NLM
products, remove the LOAD commands for those multi-NLM products from
AUTOEXEC. Load those NLMs manually after your server has completed
its boot procedure.
UPGRADING YOUR SERVER
---------------------
Step 1. Login to your NGM server as supervisor.
Step 2. Verify that your server has at least 8.0 MB of free hard disk
space. This is the recommended minimum required to perform this
upgrade.
Step 3. The contents of the NetWare Global MHS 2.0C for NW 4.01 patch
is as follows:
a. README.UPG
b. PATCH.EXE
c. PATCHNGM.BAT
d. UPGRD20C.RTP
Step 4. Copy the files 'PATCH.EXE', 'PATCHNGM.BAT', and 'UPGRD20C.RTP'
to the root NGM directory. The default NetWare Global MHS
directory is <Server\Volume:\NGM\>.
Sample: COPY PATCH.EXE <drive>:\NGM\PATCH.EXE
COPY PATCHNGM.BAT <drive>:\NGM\PATCHNGM.BAT
COPY UPGRD20C.RTP <drive>:\NGM\UPGRD20C.RTP
If you installed NetWare Global MHS in some other directory,
be sure to copy the upgrade files to that directory.
For example, if NetWare Global MHS is installed in the
directory <Server\Volume:\PUBLIC\MAIL\NGM\>, enter the following:
Sample: COPY PATCH.EXE <drive>:\PUBLIC\MAIL\NGM\PATCH.EXE
COPY PATCHNGM.BAT <drive>:\PUBLIC\MAIL\NGM\PATCHNGM.BAT
COPY UPGRD20C.RTP <drive>:\PUBLIC\MAIL\NGM\UPGRD20C.RTP
The patch program searches down through all subdirectories to find
the appropriate files to upgrade. Therefore, it is very important
to start the upgrade procedure from the correct directory.
Step 5. Unload NGM at the server console and make a backup copy of your
NetWare Global MHS Directory structure.
IMPORTANT: Do not save backup files under the same directory
structure in which you installed NetWare Global
MHS. The upgrade procedure will update the first
file within the directory structure. If this
first file happens to be a backup file, then the
correct system file may not be upgraded.
Step 6. Change to the root NGM directory (where you copied the upgrade
files). Enter:
PATCHNGM
The patch program upgrades all appropriate files. The patch
program also retains a log of the results in a file called
'RESULTS.TXT'. To verify your upgrade installation, view the
contents of 'RESULTS.TXT' after the upgrade is complete.
Step 7. During the patch process a BACKUP directory is created under
the directory from which you ran 'PATCHNGM'. The BACKUP
directory contains all files that were changed and a file
called 'UNPATCH.BAK'. After the patch process has completed
do NOT delete the BACKUP directory until you are satisfied
that the upgrade procedure was successful. If you want to
undo your upgrade and return your installation to its previous
state, perform the following procedure.
o To restore your system, change to the BACKUP directory,
copy 'UNPATCH.BAK' to 'UNPATCH.BAT', and type "UNPATCH".
This file will delete all new files in the appropriate
directories and replace them with the files which originally
existed.
o Verify the original files have been correctly re-installed.
o In order to re-run the patch process, or add additional patches,
you MUST delete or rename the BACKUP directory first. Otherwise,
the patch procedure will be unable to create an accurate BACKUP
of the changes being made during the subsequent upgrade.
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ DISCLAIMER │
│ │
│ Novell, Inc. makes no representations or warranties with respect │
│ to this software patch, and specifically disclaims any express │
│ or implied warranties of merchantability, title, or fitness for │
│ a particular purpose. │
│ │
│ Novell's intentions for this software patch is to provide a temporary │
│ work-around to the anomalies described in this file. Such │
│ work-arounds are typically addressed in future releases of │
│ NetWare Global MHS. │
│ │
│ Distribution of this patch is forbidden without the express written │
│ consent of Novell, Inc. Novell reserves the right to discontinue │
│ distribution of this software patch. │
│ │
│ Novell will not be responsible for any data loss that may result from │
│ implementing this patch. Novell strongly recommends a backup be made │
│ before any patch is applied. Technical support for this patch is │
│ provided at the discretion of Novell. │
│ │
└────────────────────────────────────────────────────────────────────────┘
